Decimal floating point numbers and floating point numbers of other radices, such as those defined by the IEEE 754-2008 Floating-Point Standard, are useful for performing certain types of data processing. IEEE 754-2008 standard based processor designs have been created to directly support the processing defined by that standard. Example hardware formats for IEEE 754-2008 processors include decimal floating point data formats that are 32, 64, and 128 bits in length with defined coefficients of 7, 16, and 34 digits with a specified exponent range. Software processing environments, such as programming languages including Java that support Decimal Floating-Point numbers, sometimes use different length coefficients, which is referred to as “precision,” with different ranges of exponents than are used by the hardware upon which the environments execute.
Decimal floating-point numbers maintain more than just the number's value, they also contain information representing the scale of the number. For instance, adding numbers that represent money in cents will generally produce a sum that is also represented in cents. Some software environments emulate decimal floating point number precision and range such that some decimal floating point operations produce results that exceed the available processing hardware precision and range. Such a condition can inadvertently lead to inaccurate results. Existing exceptions, such as inexactness, overflow and underflow exceptions, occur when the precision or range has been exceeded, but these exceptions fail to accurately detect all unexpected changes in the precision or an operation's result.
An example of an undetected potential error is a decimal floating point operation of adding two seven (7) digit monetary amounts represented in cents. Each of these source data elements would be an amount in the $10,000 range. Summing these two amounts is able to lead to an exact result in the $100,000 range. However, representing the result as cents in the $100,000 range with seven digits requires the exponent to not be the preferred exponent, which would indicate cents, and the precision of the result's value will be correspondingly reduced. Performing the same calculation with more precision would lead to an exponent indicating cents (10−2) as the scale of the result. Existing exceptions would not detect this loss of scale in the produced result.
Some hardware implementations provide a rough method of detecting the above described case. In one example, data is checked to determine if the most significant digit is non-zero. Such a check is an over indication that the result may not have the preferred exponent because some accurate results would result in a “false positive” indication. This approach effectively reduces the useful precision for emulation by one digit since the most significant digit is used as an indicator of potential loss of scale.
Therefore, calculation accuracies are limited by not detecting unexpected changes in scale or precision of decimal floating point results produced by processor formatting limitations.